Communicating With Hospitals About Updates

Some time ago, I wrote an article on the technical aspects of performing updates to your medical device in the field.¹ This article serves as a follow-up to clarify just one aspect of that topic. 

The Terminology

Before we delve any deeper into the subject matter, we first need to clarify some of the terminology of this capability. Specifically, there are three words that, at best, are used in a manner that is not clear, and, at worst, completely confuse the whole topic—Upgrade, Update, and Patch. 

All too often, these terms are mistakenly used interchangeably. The easy one to tackle is Upgrade; there is fairly broad agreement that it refers to a new version of the software that adds features or modifies the device’s essential functionality. 

One of the more surprising discoveries is that there is a dearth of good, universally accepted definitions for the words Update and Patch. Sampling the usual sources for such guidance (e.g., ISO, NIST, CISA, IMDRF, AAMI, TGA, FDA, and HSCC) revealed no consensus and few good baseline definitions, except for the FDA and the HSCC.

The FDA, in its pre- and post-market cybersecurity guidances, makes it clear there are two separate activities (i.e., “secure and timely updatability and patchability” and “duration from vulnerability identification to when it is updated or patched”), yet when it comes to their definitions, they tend to contradict how they use the terms in the body of the document.

Patch: a “repair job” for a piece of programming; also known as a “fix.” A patch is the immediate solution to an identified problem that is provided to users. The patch is not necessarily the best solution for the problem, and the product developers often find a better solution to provide when they package the product for its next release. A patch is usually developed and distributed as a replacement for or an insertion in compiled code (that is, in a binary file or object module). In many operating systems, a special program is provided to manage and track the installation of patches.

Update: corrective, preventative, adaptive, or perfective modifications made to software of a medical device.

The HSCC Joint Security Plan v2 spends a great deal of time discussing the topic of medical device updates and patches, and is probably the best source of information available on the topic. However, the use of terminology can be confusing. For example: 

Standard update: The planned maintenance activity, including updates to address known vulnerabilities, on a reasonably justified regular cycle where justification appropriately reflects the system’s architecture and associated risks over time.

Critical update: An out-of-cycle software update to address an uncontrolled risk or critical security vulnerability.

Patch Management: The systematic monitoring, identification, assessment, remediation, deployment, and verification of operating system and application software code updates. These updates are known as patches, hot fixes, and service packs to operating systems, third-party products and components, and in-house developed software.

This adds two new phrases—Standard update and Critical update—yet tends to conflict with typical industry usage, such as “hotfix” patches, which are provided on a predictable cadence. There is no separate definition of “Update,” except for the standard/critical variants defined previously. However, it is clear from its use (similar to the FDA) that it is separate from “Patch.”

Since there are so many contradictory definitions for Update and Patch, I will collectively refer to both of these as a “Deployable Fix” (from the FDA’s 2016 Post Market Cybersecurity Guidance), which should not bring any baggage or preconceived ideas about the operation of sending new software to a medical device in the field.

From product launches to M&A and manufacturing trends, the MPO Source delivers the medtech news you need twice a week. Subscribe here!

Getting Healthcare’s Compliance

While the specific security details and mitigations are very important to Deployable Fixes, even more so is getting the health delivery organizations (HDOs) to apply them to their medical devices. As such, the HDO staff needs to fully understand their level of risk without applying the Deployable Fix, so they can determine their priority for applying it. Unfortunately, this isn’t as simple as it seems.

First, let’s consider the plight of the poor person at an HDO responsible for applying Deployable Fixes. It is probably not their only responsibility, yet they may be responsible for hundreds to tens of thousands of medical devices. Further, this person will be yelled at if a medical device gets hacked, especially if a Deployable Fix is available but has not been deployed. That person is also the one yelled at if a certain medical device is not available because it has been pulled out of active use to have the fix applied. It’s the healthcare cybersecurity equivalent of being between a rock and a hard place. 

Therefore, what information can this person use to determine and justify the urgency for deploying the fix? All too often, there is very little information. Most manufacturers are going to recommend an aggressive schedule for deployment because their only consideration is the severity and exploitability of the vulnerability being corrected in the fix.

Perhaps the manufacturer recommends deployment ASAP or provides a CVSS score; can this poor HDO employee use these recommendations without factoring in the HDO’s environment (of which the manufacturer is completely oblivious)? All vulnerability scoring rubrics are subjective. Does the manufacturer’s subjectivity align with the HDO’s subjectivity? Probably not.

Remember, the quality of this communication from the manufacturer to the HDO is what is going to inform whether this latest “critical fix” is deployed today or during the next annual maintenance period. From the manufacturer’s perspective, provide all the information you can about the vulnerability and the risks it poses to the medical device and the operating environment.

This includes:

Execution

• Affected versions
• Instructions to manually and automatically apply the Deployable Fix
• Instructions to verify a Deployable Fix has been successfully applied

Risk/Priority Scoring

• CVSS (or EPSS, OWASP, No Dirt, etc.)
• CVSS vector
• CVE
• NVD
• CWE
• Impacts to other connected dependencies and interoperability (if any)
• Impacts to essential clinical performance (if any)
• Impacts to serviceability (if any)

Planning/Scheduling

• Recommended deployment timeframe
• How much time the deployment will take (best and worst case, including restoring the previous vulnerable version)
• Description of any impacts that applying the Deployable Fix can have upon the device (including any reboots)
• What, if any, retraining is needed to use this new version
• Tests that should be included in the re-validation testing performed post-deployment, before returning the device to operational status

This set of information then allows the HDO to determine the priority and risk appetite they will use.

This is not typical currently, but it is the best practice that should be the goal going forward. This is a lot of information for a manufacturer to assemble, but it is far worse for the poor person at the HDO. They may have a large number of devices to evaluate, each with potentially different installed software versions. This scales beyond human capabilities very quickly, yet no machine-readable artifact (JSON, API, etc.) is currently defined to assist in automating this process. (This really needs to be created by a standards working group.)

The medium of this communication is also a challenge: a flood of emails, text messages, websites, telephone calls, postal mail, device screen notifications, or some combination thereof?

What happens when the HDO representative the manufacturer knows leaves? This is why all of this needs to be automated to avoid these obvious failures in delivering what can easily be critical information to the HDO and to initiate the deployment process.

After considering the previous three paragraphs, I decided this needed a machine-readable solution so I reached out to my friend Steve Springett, the original creator of the premier SBOM format “CycloneDX.” (It is much more than an SBOM; it can include all information that needs to be shared—xBOMs.) Steve graciously offered to add the bulleted fields to an upcoming release of CycloneDX. This comes with ECMA TC54 standard compliance (and thus ISO as well) and means CycloneDX’s Transparency Exchange API (aka “TEA”) can also be used for sharing the BOM information. Since TEA is a format-agnostic, standardized interface designed to automate the discovery, publication, and retrieval of supply chain artifacts, it enables secure, machine-to-machine exchange of xBOMs. So very shortly, we will have a machine-to-machine method to keep hospitals informed about the status of Deployable Fixes for the medical devices in their organization. 

Reciprocating Back to the Manufacturer

While the HDO is the entity that will suffer the consequences of an attack on a medical device, the manufacturer is the entity legally responsible for crafting and issuing Deployable Fixes and using metrics to track the deployment process. But typically, the manufacturer has no insight into this process once the Deployable Fix is released and notifications are sent to the HDO.

This is where the HDO can really assist the overall process by responding to the manufacturer with specifics about the success/failure/delay of each Deployable Fix. Once again, there is no standard communication medium to accomplish this, so we’re back to emails, websites, telephone calls, etc. This process also needs a standard approach defined by a working group that can easily scale for both the HDO and the manufacturer.

Legal- and regulatory-defined security operations are great and keep us all safer, but we do need standards and processes to help us achieve the goals of this concept.

Reference

1. tinyurl.com/mpo260721 

More from this author: The Butterfly Effect of AI on Cybersecurity

Christopher Gates is the founder and CEO of arsMedSecurity, a medtech cybersecurity consulting firm. He is a recognized thought leader in medical device cybersecurity and the current co-chair for H-ISAC’s MDSC. Gates has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, and Bluetooth SIG.